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Abstract. Concurrent ML's events and event combinators facilitate modular con- 
current programming with first-class synchronization abstractions. A standard 
implementation of these abstractions relies on fairly complex manipulations of 
first-class continuations in the underlying language. In this paper, we present a 
lightweight implementation of these abstractions in Concurrent Haskell, a lan- 
guage that already provides first-order message passing. At the heart of our imple- 
mentation is a new distributed synchronization protocol. In contrast with several 
previous translations of event abstractions in concurrent languages, we remain 
faithful to the standard semantics for events and event combinators; for example, 
we retain the symmetry of choose for expressing selective communication. 

1 First-class synchronization abstractions 

In his doctoral thesis ||l2l . Reppy invents the concept of first-class synchrony to facili- 
tate modular concurrent programming in ML. He argues: 

Unfortunately there is a fundamental conflict between the desire for abstraction and the 
need for selective communication [in concurrent programs]. . . .To resolve the conflict 
. . . requires introducing a new abstraction mechanism that preserves the synchronous 
nature of the abstraction. 

Thus, Reppy introduces a new type constructor event to type synchronous operations 
in much the same way as — > ("arrow") types functional values. 

This allows us to represent synchronous operations as first-class values, instead of 
merely as functions . . . [and design] a collection of combinators for defining new event 
values [from primitive ones] .... Selective communication is expressed as a choice among 
event values, which means that user-defined abstractions can be used in a selective 
communication without breaking the abstraction. 

Reppy implements events in an extension of ML, called Concurrent ML (CML) ff3l . 
and provides a formal semantics for synchronization of events [ 12]. While the imple- 
mentation itself is fairly complex, it allows programmers to write sophisticated com- 
munication and synchronization protocols as first-class abstractions in the resulting lan- 
guage. Next, we provide a brief introduction to CML's events and event combinators. 
The interested reader can find a more detailed account of first-class synchrony and its 
significance as a programming paradigm for concurrency in fl"3l . 

In particular, note that channel and event are polymorphic type constructors in 
CML, as follows: 



- The type channel r is given to channels that carry values of type r. 

- The type event r is given to events that return values of type r on synchronization. 

The combinators receive and transmit can build primitive events for synchronous 
communication. 

receive : channel r — * event r 
transmit : channel r — > r — > event () 

- receive creturns an event that, on synchronization, accepts a message M on chan- 
nel c and returns M. Such an event must synchronize with transmit c M. 

- transmit c M returns an event that, on synchronization, sends the message M on 
channel c and returns () ("unit"). Such an event must synchronize with receive c. 

The combinator choose can non-deterministically select an event from a list of events, 
so that the selected event can be synchronized. In particular, choose can express any 
selective communication. 

The combinator wrapabort can specify an action that is spawned if an event is not 
selected by a choose. 

choose : [event r] — > event r 
wrapabort :(()—►())—* event r — > event r 

- choose V returns an event that, on synchronization, synchronizes one of the events 
in list V and "aborts" the other events. 

- wrapabort / v returns an event that, on synchronization, synchronizes the event 
v, and on abortion, spawns a thread that runs the code / (). Here, if v itself is of 
the form choose V and one of the events in V is selected, then v is considered 
selected, so / is not spawned. 

The combinators guard and wrap can specify actions that are run before and after 
synchronization, respectively. 

guard :(()—> event r) — ► event t 

wrap : event r — > (r — > r ) — » event r 

- guard / returns an event that, on synchronization, synchronizes the event returned 
by the code / (). Here, / () is run every time a thread tries to synchronize guard /. 

- wrap v / returns an event that, on synchronization, synchronizes the event v and 
applies function / to the result. 

Finally, the function sync can synchronize an event and return the result. 

sync : event r — > r 

Note that by construction, an event can synchronize at exactly one "commit point", 
where a message is either sent or accepted on a channel. This commit point may be 
selected among several other, potential commit points. Some code may be run before 
synchronization, as specified by guard functions throughout the event. Some more code 
may be run after synchronization, as specified by wrap functions that surround the 
commit point, and by wrapabort functions that do not surround the commit point. 



Reppy's implementation of synchronization involves fairly complex manipulations 
of first-class continuations in phases 11311 . Even the channel communication functions 

accept : channel r — > r 
send : channel r — > r — ► () 

are derived by synchronization on the respective base events. 

accept c = sync (receive c) 
send c M = sync (transmit c M) 

In contrast, in this paper we show how to implement first-class event synchronization 
in a language that already provides first-order synchronous communication. Our imple- 
mentation relies on a new distributed synchronization protocol, which we formalize as 
an abstract state machine and prove correct (Section^. We concretely implement this 
protocol by message passing in Concurrent Haskell |8), a language that is quite close to 
the pi calculus 1111 . Building on this implementation, we present an encoding of CML 
events and event combinators in Concurrent Haskell (Sections[3]and[4]i. 

We are certainly not the first to encode CML-style concurrency primitives in another 
language. However, a lightweight implementation of first-class event synchronization 
by message passing, in the exact sense of Reppy fl2l . has not appeared before. We defer 
a more detailed discussion on related work to Section[6] 

Before we present our protocol, we introduce its main ideas through the following 
(fictional) narrative, which describes an analogous protocol for arranging marriages. 

In the Land of Frig, there are many young inhabitants who are eager to get 
married. At the same time, the rivalry among siblings is so fierce that if a 
young man or woman gets married, his or her siblings commit suicide. There 
are many priests, who serve as matchmakers. Eager young inhabitants flock to 
these matchmakers to meet prospective partners of the opposite sex. When two 
such partners meet, they reserve the priest who matches them, and then inform 
their parents. Meanwhile, the priest stops matching other couples. 

Parents select the first child to inform them about meeting a partner, and 
send their approval to the concerned priest. For all other children who are too 
late, on the other hand, they send back their refusal. If a priest receives approval 
from both parties, he confirms the marriage date to both sides; following this 
information, the couple weds. If one party refuses and the other approves, the 
priest alerts the approving side that the impending marriage must be canceled; 
following this information, the young members of that family begin searching 
for partners once again. The priest now resumes matching other couples. 

Obviously, we would like to have progress in the Land of Frig — weddings should be 
possible as long as there remain eligible couples. Can we prove this property? Yes. We 
first prove the following lemma: if there remain two inhabitants of opposite sex who are 
looking for partners, a priest can eventually match them. Indeed, pick any priest. Either 
that priest is free, or two partners who have already met have reserved that priest. In the 
latter case, both partners inform their parents; both parents send their decisions to the 
priest; therefore, the priest is eventually free. 



Now, suppose that there remain two inhabitants A and B of opposite sex who are 
looking for partners. Then (by the lemma above) a priest eventually matches them. Next, 
A and B inform their parents. Now, if both A and B are the first among their siblings to 
inform their parents, they eventually get married and we are done. On the other hand, 
suppose that one of A\ siblings informs A's parent first. (Clearly, that sibling could not 
have been married when A was looking for partners, since otherwise, A would have 
been dead, not looking for partners.) Now, either that sibling gets married, and we are 
done; or, that sibling does not get married, and A tries again. Similarly, either one of B's 
siblings gets married and we are done, or B tries again. Now, if A and B both try again, 
they can be the first among their siblings to inform their parents; so, they eventually get 
married, and we are done. 



2 A distributed event synchronization protocol 

We now present a distributed protocol for synchronizing events, that is based on the 
protocol for arranging marriages in the Land of Frig. Specifically, we interpret 

- young inhabitants as potential commit points, or simply, points; 

- priests as channels; 

- parents as synchronization sites, or simply, synchronizers. 

In other words, points, channels, and synchronizers are principals in our protocol. A 
point is a site of pending input or output on a channel — every receive or transmit 
event contains a point. Every application of sync contains a synchronizer. 

We focus on synchronization of events that are built with the combinators receive, 
transmit, and choose. The other combinators do not fundamentally affect the proto- 
col; we consider them only in the concrete implementation in Section[3] 



A source language For brevity, we simplify the syntax of the source language. 

- Actions a, (3 are of the form core (input or output on channel c). 

- Programs are of the form S\\ ... | S„ (parallel composition of Si, . . . , S n ), where 
each Si is either an action a, or a synchronization of a choice of actions select( a ). 

Further, we consider only the following local reduction rule, which models selective 

communication: _> —f 

c G a c£ p 



select(af) | select(/3) 



besides the usual structural rules for parallel composition. In particular, we ignore re- 
duction of actions at this level of abstraction. 



A distributed abstract state machine for synchronization We formalize our protocol 
as a distributed abstract state machine that implements the above semantics of selective 
communication. Let a range over states of the machine. These states may be of the 
form a \ a' (parallel composition), (vp) a (name restriction), or (sub-state of some 
principal in the protocol). Sub-states may be of the following forms. 



<T P :: 



p i — ► a 
Candidate,, 



Match c (p, q) 



sub-states of points 
unmatched 
matched 
married 
sub-states of channels 
free 
busy 



<T S ::= sub-states of synchronizers 

□ s open 
K s closed 
Select^ (p) approved 
Reject (p) refused 
Do n e s (p) confirmed 
Retry s canceled 



Here p, c, and s range over points, channels, and synchronizers. A synchronizer is a par- 
tial function from points to actions; we represent this function as a parallel composition 
of bindings of the form p i— > a. Further, we require that each point belongs to exactly 
one synchronizer, that is, for any s and s', s ^ s' dom(s) n dom(s') = 0. The 
semantics of the machine is described by the following local transition rules, plus the 
usual structural rules for parallel composition and name restriction (cf. the pi calcu- 
lus ifTTl . for example). In Section [3] these rules are implemented by message passing 
between appropriate processes run at points, channels, and synchronizers. 



p c | q i— > c | C 
p G dom(s) 



Candidate^ | Candidate^ | Match c (p, q) (I) 



Candidate,, I 



Select^ (p) 



(ILi) 



p G dom(s) 



Candidate,, 



s ->• B a | Reject (p) 

Select s (p) | Selects- (g) | Match c (p, q) -> Done s (p) | Done s /(g) | C (IILi) 
Selects(p) | Reject(g) | Match c (p, g) -> Retry s | C (Ill.ii) 
Reject(p) | Selects(q) | Match c (p, q) -> Retry s | C (IILiii) 
Reject(p) | Reject(g) | Match c (p, q) C (Ill.iv) 
s(p) = a _ dom(s) = p 



(ILii) 



(IV.i) 



Retry, (i/^) | s) 



(IV.ii) 



Done s (p) -> 
The rules may be read as follows. 

(I) Two points p and q, bound to complementary actions on channel c, react with c if it 

is free (0 C ), so that p and q become candidates and the channel becomes busy. 
(Il.i-ii) Next, p (and likewise, q) reacts with its synchronizer s. If the synchronizer 

is open (□«), it now becomes closed (M s ), and p is declared selected by s. If the 

synchronizer is already closed, then p is rejected. 
(ULi-iv) If both p and q are selected, c confirms the selections to both parties. If only 

one of them is selected, c cancels that selection. The channel now becomes free. 
(IV.i-ii) If the selection of p is confirmed, the action bound to p is released. Otherwise, 

the synchronizer "reboots" with fresh names for the points in its domain. 



Compilation We compile the source language to this machine. Let the symbol 77 de- 
note finite parallel composition. Suppose that the set of channels in a program TT^gi „5i 
is C. We compile this program to the state 77 ce c C | niei.. n Si, where 




(vp~j) (Ds | s) if S = select(cij), where s = II "j (pj \— » ay) for fresh names pj 



Correctness We prove that our protocol is correct, that is, the abstract machine cor- 
rectly implements selective communication, by showing that the compilation from pro- 
grams to states preserves progress and safety. Let a denotation be a list of actions. The 
denotations of programs and states are derived by the function r - n , as follows. 

i_ ~ I . „ _, _, ro _, r <7 I (t'" 1 = r er~ l tbl r (T / ~ l 

r 5i | ... | 5„ n = r sr w • • • a r s r r . [ 

r {vp) <T n = r cr n 

a 1 = [a] 

v 1 u otherwise 

Now, if a program is compiled to some state, then the denotations of the program and 
the state coincide. Further, we have the following theorem, proved in the appendix. 

Theorem 1 (Correctness). Let C be the set of channels in a program 77; g i..„SV Then 
TTigi. nS'i ~ 77 cg c 0c | IIi£i.. n Si, where ~ is the largest relation such that V ~ a iff 

(Correspondence) a — >•* a' for some a' such that r V n = r <r'~ l ; 

(Safety) if a — > a' for some a', then V — >* V for some V such that V' ~ & '; 

(Progress) ifV — > -, then a — > + a' and V — ► V for some a 1 and V' such that V' ~ a'. 

Example Consider the program select (x, y) | select(y, z) | select (z) | select(x). The 
program can reduce either to x \ z \ ~z \ x, or to y \ y | select (j) | select(x). The 
denotations of these reduced programs are {x, x,~z, z} and {y, y}, respectively. The 
original program is compiled to the state 

©x I Q v | Q z (vp s py) (□( Ps ^ 3 r | py^y) \ Px^x\p y ^y)\ 

(vPyPz) ( a (p v ^y | p z ^z) | Py ^ V | Pz "-»■ Z) \ 
(VPs) ( n (p^¥) \Pz^z)\ 

(yPx) (a ip ^ x) I p x h-> x) 

This state can transition in multiple steps to either of the following states, with de- 
notations {x, x,~z, z} and {y,y}, respectively. (In these states, o~j un k can be garbage- 
collected, and is separated out for readability.) 

- X | Z | Z I X I Q x I Qy I Q z | CTjunk 

- V I V I ("Pis) i n (p^z) \ Pz<~>z)\ {vPx) (n^^x) I Px X) I Q x I Q y I Qz I O-jtrn* 
O-junft - iyPxPyPyPzPzPx) (®(p s ^x \ p y ^y) I ^(p^j, | p z ^z) I ^(p^z) I ^(p*,^)) 



3 A concrete implementation in Concurrent Haskell 

The abstract machine of the previous section can be concretely implemented by a sys- 
tem of communicating processes. Indeed, we now present a complete implementation 
of a CML-style event library in a fragment of Concurrent Haskell with first-order mes- 
sage passing. This fragment is rather close to the pi calculus. Thus, we ensure that our 
implementation can be ported without difficulty to languages that support first-order 
communication. At the same time, we take advantage of Haskell's type system to show 
how events and event combinators can be typed under the IO monad 17191 . 



Before we proceed, we briefly review some of the concurrency primitives in Concur- 
rent Haskell. Note that MVar and IO are polymorphic type constructors, as follows: 

- The type MVar r is given to a communication cell that carries values of type r. 

- The type IO r is given to a computation that yields results of type r, with possible 
side effects via communication. 

We rely on the following semantics of MVar cells. 

- A cell can carry at most one value at a time. 

- The function New :: IO (MVar r) returns a fresh, empty cell. 

- The function Get :: MVar r — » IO r is used to read from a cell; Get m blocks if 
the cell m is empty, else gets the content of m (thereby emptying it). 

- The function Put :: MVar r — > t — » IO () is used to write to a cell; Put m M 
puts the term M in cell m if it is empty, else blocks. 

Further, we rely on the following semantics of IO computations. 

- The function fork :: IO () — * IO () is used to spawn a concurrent computation. 

- The function return :: r — > IO r is used to inject a value into a computation. 

- Computations can be sequentially composed by "piping". We use Haskell's conve- 
nient do{. } notation for this purpose, instead of applying the de jure function 
. »= _ :: IO r -> (r -► IO r ) -> IO t'. 



Implementing synchronization by message passing We implement the following 
functions for programming with first-class events in Concurrent Haskell. (Note the dif- 
ferences between ML and Haskell types for these functions. Since Haskell is purely 
functional, we must embed types for computations with possible side-effects via com- 
munication, within the IO monad. Further, since evaluation in Haskell is lazy, we can 
discard abstractions that only serve to "delay" evaluation.) 

new :: IO (channel r) 
receive :: channel r — > event r 
transmit :: channel r — > r — > event () 
guard : : IO (event r) — > event r 
wrap :: event r — > (r — > IO r') — > event r' 
choose :: [event r] — > event r 
wrapabort :: IO () — ► event r — > event r 
sync :: event r — > IO r 

For now, we focus on events that are built without wrapabort (i.e., we focus on pro- 
grams without abort actions); the full implementation appears in SectionH] 

We begin by concretizing the abstract state machine in Section [2] Specifically, we 
run some protocol code at points, channels, and synchronizers, which reduce by simple 
message passing on MVar cells. In this implementation: 



- Each point is identified with a fresh name p :: Point. 



- Each channel c is identified with a pair of fresh cells wv°> :: In and out^ :: Out 
on which it receives messages from points that are bound to actions on c. 

- Each synchronizer is identified with a fresh cell s :: Synchronizer on which it 
receives messages from points in its domain. 

Before we present protocol code, let us describe the sequence of messages exchanged 
in a typical session of the protocol, and mention the involved sub-states. On the way, we 
develop type definitions for the MVar cells on which those messages are exchanged. 

- A point p (at state p i— > c or p i— > c) begins by sending a message to c on its 
respective input or output cell infi or out^; the message contains a fresh cell 
candidate ^ : : Candidate on which p expects a reply from c. 

type In = MVar Candidate 
type Out = MVar Candidate 

- When c (at state © c ) gets a pair of messages on in^ and out^ c \ say from p and 
another point q, it replies by sending fresh cells decision^ :: Decision and 
decision^ :: Decision on candidate^ and candidate^ respectively (reaching 
state Match c (p, q)), and expects the synchronizers forp and q to reply on them. 

type Candidate = MVar Decision 

- On receiving a message from c on candidate^, p (reaching state Candidate^) tags 
the message with its name and forwards it to its synchronizer on the cell s. 

type Synchronizer = MVar (Point, Decision) 

- If p is the first point to send such a message on s (that is, s is at state □„), a fresh cell 
commit^ :: Commit is sent back on decision (reaching state Kl s | Select s (p)); 
for each subsequent message received on s, say from p', a blank message is sent 
back on decision^ ' (reaching state M s | Reject(p')). 

type Decision = MVar (Maybe Commit )Q 

- On receiving messages from the respective synchronizers of p and q on decision^ 
and decision^, c inspects the messages and responds (reaching state C ). 

• If both commit^ and commit^ have come in, a positive signal is sent back 
on commit^ and commit^. 

• If only commit^ has come in, a negative signal is sent back on commit^; if 
only commit^ has come in, a negative signal is sent back on commit^. 

type Commit = MVar Bool 

- If s receives a positive signal on commit^ (reaching state Dones^p)), it signals 
on p to continue. If, instead, a negative signal is received (reaching state Retry s ), 
another session ensues. 

type Point = MVar () 

1 Recall that the Haskell type Maybe r is given to a value that is either Nothing, or of the 
form Just v where v is of type r. The function maybe :: r' — > (r — > r') — > Maybe r — > r' 
is the associated case analyzer. For instance, the function is Just :: Maybe r — > Bool is 
defined as maybe False (A_. True). 



Protocol code for points The protocol code run by points abstracts on a cell s for the 
associated synchronizer, and a name p for the point itself. Depending on whether the 
point is for input or output, the code additionally abstracts on an input cell i or output 
cell o, and an input or output action a. 

©Point I :: Synchronizer — > Point — > In — > IO r — > IO r 
©Point I s p i oc = do {candidate <— New; Put i candidate; 

decision <— Get candidate; Put s (p, decision); 

Get i; a} 

@PointO :: Synchronizer — > Point — > Out — > IO () -» IO () 
©Point spoa = do {candidate <— New; Put o candidate; 

decision <— Get candidate; Put s (p, decision); 

Get t; a} 

Protocol code for channels The protocol code run by channels abstracts on an input 
cell i and an output cell o for the channel. 

@Chan :: In -*■ Out -> IO () 

@Chan i o = do {candidate <— Get i; candidate <— Get o; 

decisioni <— New; Put candidate^ decision^ x, <— Get decision^ 
decision Q <— New; Put candidate Q decision a ; x *— Get decision Q ; 
maybe (return ()) (\commiti. Put commiti (isJust x Q )) x^; 
maybe (return ()) (\commit . Put commit (isJust Xj)) x } 

Protocol code for synchronizers The protocol code run by synchronizers abstracts on 
a cell s for that synchronizer and some "rebooting code" X. (Here, we encode a loop 
with the function f ix :: (r — > t) — > t; recall that f ix / reduces to / (fix /).) 

@Sync :: Synchronizer IO () — > IO () 

@Sync s X = do {(p, decision) ^— Get s; 

fork (fix (Xiter. do { 

(p', decision 1 ) <— Get s; Put decision 1 Nothing; iter})); 
commit <— New; Put decision (Just commit); 
done <— Get commit; if done then (Put p ()) else X} 

We instantiate these processes in the translation of new, receive, transmit, and sync 
below. But first, let us translate types for channels and events. 

Translation of types The Haskell types for ML channel and event values are: 

channel r = (In, Out, MVar r) 
event r = Synchronizer — » IO r 

An ML channel is a Haskell MVar tagged with a pair of input and output cells. An 
ML event is a Haskell IO function that abstracts on a synchronizer cell. 



Translation of functions We now translate functions for programming with events. 
We begin by compiling the ML function for creating channels. 

new :: IO (channel r) 

new = do {i <— New; o <— New; 

fork (fix (Aiter. do {@Chani o; iter})); 
m <— New; return (i, o, m)} 

- The term new spawns a looping instance of @Chan with a fresh pair of input and 
output cells, and returns that pair along with a fresh MVar cell that carries mes- 
sages for the channel. 

Next, we compile the ML combinators for building base communication events. Recall 
that a Haskell event is an IO function that abstracts on the cell of its synchronizer. 

receive :: channel r — > event r 

receive (i, o, m) = As. do {p <— New; @PointI s pi (Get m)} 
transmit :: channel r — > r — > event () 

transmit (i, o, m) M = As. do {p <— New; ©PointO spo (Put m M)} 

- The term receive c s runs an instance of @PointI with the synchronizer s, a 
fresh name for the point, the input cell for channel c, and an action that inputs on c. 

- The term transmit c M s is symmetric; it runs an instance of @PointO with 
the synchronizer s, a fresh name for the point, the output cell for channel c, and an 
action that outputs term M on c. 

Next, we compile the ML event combinators for specifying actions that are run before 
and after synchronization. 

guard :: IO (event r) — > event r 
guard / = As. do {v <— /; v s} 

wrap :: event r — > (t — > IO r') — > event r' 
wrap v f = As. do {a; <— i> s; / x} 

- The term guard / s runs the computation / and passes the synchronizer cell s to 
the event returned by the computation. 

- The term wrap v f s passes the synchronizer cell s to the event v and pipes the 
returned value to function /. 

Next, we compile the ML combinator for choosing among a list of events. (Here, we 
encode recursion over a list with the function fold :: (r' — > r — > r') — > r' — > [r] — > 
r'; recall that fold / x [] reduces to x and fold / x [i>, V] reduces to fold / (/ xv) V.) 

choose :: [event r] —> event r 
choose V = As. do {temp <— New; 

fold (A_ w. fork (do {x <— u s; Put temp x})) () V; 

Get temp} 



- The term choose V s spawns a thread for each event v in V, passing the synchro- 
nizer s to v; any value returned by one of these threads is collected in a fresh cell 
temp and returned. 

Finally, we compile the ML function for event synchronization. 

sync :: event r — > IO r 

sync v = do {temp New; 

fork (fix (Xiter. do { 

s <— New; fork (@Sync s iter); x <— V s; Put temp x})); 

Get temp} 

- The term sync v recursively spawns an instance of @Sync with a fresh synchro- 
nizer s and passes s to the event v; any value returned by one of these instances is 
collected in a fresh cell temp and returned. 

4 Compiling abort actions 

The implementation of the previous section does not account for wrapabort. We now 
show how wrapabort can be handled by slightly extending our notion of event. 

Recall that abort actions (such as those specified by wrapabort) are spawned only 
at events that do not enclose the commit point. Therefore, in an implementation of 
wrapabort, it makes sense to name events with the sets of points they enclose. How- 
ever, computing the set of points that an event encloses should not interfere with the dy- 
namic semantics. In particular, for an event built with guard, we cannot run the guard 
functions to compute the set of points that the event encloses. Thus, we refrain from 
naming events at compile time. Instead, we introduce events as principals in our proto- 
col; each event is named in situ by computing the list of points it encloses at runtime. 
This list is carried on a fresh cell name :: Name for the event. 

type Name = MVar [Point] 

Further, each synchronizer carries a fresh cell abort :: Abort on which it receives 
wrapabort functions from events, tagged with the list of points they enclose. 

type Abort = MVar ([Point], IO ()) 

Protocol code run by points and channels remain the same. We add a handler for 
wrapabort functions to the protocol code run by synchronizers. Accordingly, the code 
now abstracts on an abort cell. 

@Sync :: Synchronizer — > Abort — > IO () — > IO () 

@Sync s abort X = do {. . . ; 

if done then do {. . . ; 

fix (Xiter. do { 

(P, /) <— Get abort; fork iter; 

if p £ P then return () else /})} 

else . . . } 



Here, after signaling the commit point p to continue (as earlier), the synchronizer con- 
tinues to accept abort code / on abort; such code is spawned only if the list of points 
P, enclosed by the event that sends that code, does not include p. 
The extended Haskell type for event values is as follows. 

event r = Synchronizer — > Name — ► Abort — > IO r 

Now, an ML event is a Haskell IO function that abstracts on a synchronizer, an abort 
cell, and a name cell that carries the list of points the event encloses. 

The Haskell function new does not change. We highlight minor changes in the re- 
maining translations. We begin with the functions transmit and receive. An event 
built with either function is named by a singleton containing the name of that point. 

transmit (i, o, to) Ad = As name abort, do {. . . ; fork (Put name [p]); . . . } 
receive (i, o, to) = As name abort, do {. . . ; fork (Put name [p]); . . . } 

The function choose becomes slightly lengthy. A fresh name' cell is passed to each 
event in the list; the names of those events are concatenated to name the choose event. 

choose V = As name abort, do {. . . ; 

P <- fold (XPv. do { 
name' <— New; 

fork (do {x <— V s name' abort; •••}); 

P <— Get name'; Put name' P ; 

return (P'ttP)}) [] V; 
fork (Put name P); 
...} 

We now compile the ML event combinator for specifying abort actions, 
wrapabort :: IO () — > event r — » event r 
wrapabort / v = As name abort, do { 

fork (do {P <— Get name; Put name P; Put abort (P, /)}); 

v s name abort} 

- The term wrapabort / v s name abort spawns a thread that reads the list of 
enclosed events P on the cell name and sends the function / along with P on the 
cell abort; the synchronizer s is passed to the event v along with name and abort. 

The functions guard and wrap remain similar. 

guard / = As name abort, do {v <— /; v s name abort} 
wrap v f — As name abort, do {x <— v s name abort; f x} 

Finally, in the function sync, a fresh abort cell is now passed to @Sync, and a fresh 
name cell is created for the event to be synchronized. 



sync v = do {. . . ; 

fork (fix (Xiter. do { 

. . . ; name <— New; abort <— New: 

fork (@Sync s abort iter); i<~»s name abort; . . . })); 
...} 

5 Implementing communication guards 

Beyond the standard primitives for communication in CML, some previous implemen- 
tations of events further consider guarded communication. We discuss how our im- 
plementation can be easily extended to handle such communication. Specifically, we 
require the following receive combinator, that can carry a communication guard. 

receive :: channel r — > (r — > Bool) — > event r 

Intuitively, receive c cond synchronizes with transmit c M only if condM is true. 
In our implementation, we make some slight adjustments to the types of some MVar 
cells. 

type In t = MVar (Candidate, r — > Bool) 
type Out t = MVar (Candidate, r) 
type Candidate = MVar (Maybe Decision) 

Next, we adjust the protocol code run by points and channels. Input and output points 
that are bound to actions on c respectively send their conditions and messages to c. A 
pair of points is matched only if the message of one satisfies the condition of the other. 

@Chan :: In r — » Out r -> IO () 

©Chan i o = do {(candidate j, cond) <— Get i; (candidate 01 M) <— Get o; 
if (cond M) then do { 

. . . ; Put candidatei (Just decision^); . . . ; 
. . . ; Put candidate a (Just decision^); . . . ; 
...} 

else do {Put candidatei Nothing; Put candidatei Nothing}} 
@PointI :: Synchronizer — > Point — > In r — > (t — > Bool) — ► IO r — > IO r 
@PointI s pi cond a = do {. . . ; Put i (candidate, cond); 

x *— Get candidate; 

maybe (@PointI s pi cond a) 

(Xdecision. do {Put s (p, decision); . . .}) x} 
@PointO :: Synchronizer — > Point — > Out r — > r — > IO () — > IO () 
@PointO s p o M a = do {. . . ; Put o (candidate, M); 

x *— Get candidate; 

maybe (@PointD s p o M a) 

(Xdecision . do {Put s (p, decision); . . .}) x} 



Finally, we make the following trivial adjustments to the type constructor channel, 
and the functions receive and transmit. 

type channel r = (In r, Out r, MVar r) 
receive (i, o, m) cond = As name abort, do {. . . ; @PointI s pi cond (Get m)} 
transmit (£, o, m) M = As name abort, do {. . . ; @PointO s p o M (Put m M)} 

6 Related work 

We are not the first to implement CML-style concurrency primitives in another lan- 
guage. In particular, Russell presents an implementation of events in Concurrent Haskell 
in lfl4l . The implementation provides guarded channels, which filter communication 
based on conditions on message values (as in Section[5]l. Unfortunately, the implemen- 
tation requires a rather complex Haskell type for event values. In particular, a value of 
type event r must carry (among other things) a continuation of type IO r — > IO (). 
An important difference between Russell's implementation and ours is that Russell's 
choose combinator is asymmetric. In contrast, we implement a symmetric choose 
combinator, following the standard CML semantics. While it is difficult to compare 
other aspects of our implementations, we should point out that Russell's event library is 
more than 1300 lines of Haskell code (without comments), compared to our 150. Yet, 
guarded communication in the sense of Russell can be readily implemented in our set- 
ting, as shown in Section In the end, we believe that this difference in complexity is 
largely due to the elegance of our synchronization protocol. 

Recently, Donnelly and Fluet Q introduce transactional events and implement 
them over the software transactional memory (STM) module in Concurrent Haskell. 
Their key observation is that combining all-or-nothing transactions with CML-style 
concurrency recovers a monad. Unfortunately, implementing transactional events re- 
quires solving NP-hard problems |5 |. In contrast, our direct implementation of CML- 
style concurrency remains rather lightweight. 

Other implementations of events include those of Flatt and Findler in Scheme J6] 
and of Demaine in Java 0J. While Flatt and Findler focus on kill-safety, Demaine fo- 
cuses on efficiency by exploiting communication patterns that involve either single re- 
ceivers or single senders. Demaine does not consider event combinators — in particular, 
it is not clear whether his implementation can accommodate abort actions. 

Distributed protocols for implementing selective communication date back to the 
1980s. The protocols of Buckley and Silberschatz |3| and Bagrodia Q] seem to be 
among the earliest in this line of work. Unfortunately, those protocols are prone to 
deadlock. Bornat J2) proposes a protocol that is deadlock-free assuming communica- 
tion between single receivers and single senders. Finally in ifTOl . Knabe presents the 
first deadlock-free protocol to implement selective communication for arbitrary chan- 
nel communication. Knabe's protocol appears to be the closest to ours. Channels are 
considered as sites of control, and messages are exchanged between communication 
points and channels to negotiate synchronization. However, Knabe assumes a global 
ordering on processes and maintains queues for matching points; we do not require ei- 
ther of these facilities in our protocol. Moreover, as in |4j, it is not clear whether the 
protocol can accommodate event combinators such as guard and wrapabort. 



7 Conclusion 



In this paper, we show how to implement first-class event synchronization in Concur- 
rent Haskell, a language with first-order message passing. We appear to be the first to 
implement the standard semantics for events and event combinators in this setting. An 
interesting consequence of our work is that implementing distributed selective commu- 
nication is reduced to implementing distributed message-passing in Concurrent Haskell. 
At the heart of our implementation is a new deadlock-free protocol that is run among 
communication points, channels, and synchronization sites. This protocol seems to be 
robust enough to allow implementations of sophisticated synchronization primitives. 
All the code presented in this paper is available online at 

|http : / / www . soe . ucsc . edu/~avik/pro jects/CML| 
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A Correctness proof for the synchronization protocol 



In this appendix, we prove correctness of the synchronization protocol (Theorem [TJ. 
This proof closely follows the informal proof of progress in the Land of Frig. 

Consider any state a. We begin by defining some invariants that a must satisfy; 
the satisfaction of these invariants is written as h a. Let a be in the form (vP) 77"?*. 
We assume that the set of points in <r is P, the set of channels in <; is C, the set of 
synchronizers in <r is S, and C n P = 0. Then h a if: 

1. For any p G V, there is a unique seS such that p G dom(s). Further, let s(p) = a. 
Then at most one of the following sub-states is in ? : 

{p t— » a, Candidate p , Selects (p), Reject (p), Done s (p), Retry,.} 

and exactly one of the following sub-states is in c : 

{a s M s } 

2. For every c G C, exactly one of the following sub-states is in ? : 

{0 c ,Match c (_, _)} 

3. Let p G P and s £ S such that p G dom(s). Then, if one of the following sub-states 
is in c : 

{Selects (p), Reject(p), Done s (p), Retry s } 

then K s is in On the other hand, if S s is in ~<f then there is at most one p such 
that p G dom(s) and one of the following sub-states is in ? : 

{Selects(p), Done s (p), Retry s } 

4. Let c G C and p,q <E P. Then Match c (p, g) is in c iff there are (not necessarily 
distinct) s, s'£<S such that s(p) = c, s'(g) = c, one of the following sub-states is 
in 

{Candidate p , Select s (p), Reject(p)} 
and one of the following sub-states is in £ : 

{Candidate^, Selects- (q), Reject(q)} 

It is easy to see that (1^4) are invariants for any state compiled from a program. 

Lemma 1. Let C be the set of channels in a program iTjgi. . n Si- Now, suppose that 
n ce c 0c | n ie i..„Si a. Then h a. 

Next, we prove the analog of the lemma in SectionQ] 

Lemma 2. Suppose that h {vP) TI~^. Let p, q G P, and let p i— > c and q i— > c be in 
Then (vP) LJ~^ — >* [yP)II<;' such that © c is in . 



Proof. If C is in <; , we are done. Otherwise, by (2) it follows that Match c (j/, q') in 
in ^ for some p',q' G P. Now, by (1) and (4), p' 7^ p and q' ^ q. Further, by (4), 
there are s and s' in the set of synchronizers in q such that p 1 G dom(s), q' € dom(s'), 
Candidate p / or Select s (p') or Reject(p') is in ? , and Candidate,* or Selects (c/') or 
Reject(g') is in ^ . Further, by (1), D s or Kl s is in ^ , and D s / or Kl s / is in ? . Now, 

(Il.i-ii) can be applied to move to a state (vP)IIc," such that Select s (p') or Reject(p') 

is in and Selects (q 1 ) or Reject(c/') is in <;". Finally, (IILi-iv) can be applied to move 

to the required state (vP)II ^' . 

We are now ready to prove the main theorem. 

Restatement of Theorem[TJ Let C be the set of channels in a program 7I; e i ,. n Si- Then 
7Ti e i..„5i ~ i7 c gc ©c I Hiel..nS%, where ~ is the largest relation such that V ~ a iff 

(Correspondence) a — ►* cr' for some er' such that r P n = r cr' n ; 

(Safety) if a — > cr' for some cr', then P — ►* P' for some P' such that P' ~ cr'; 

(Progress) if P — ► _, then cr ^ + cr' and P — > P' for some cr' and P' such that P' ~ cr'. 

Proof. The proof of (Safety) is fairly easy. (Progress) follows from Lemmas[T]and|2] as 
follows. By LemmaQ] we can consider only a subset ~ of ~ such that _ ~ cr =^> h cr. 
Now, suppose that P ~ (vP) c and P — > _. 

We first assume that there are some p ^ c and q 1— > c in c . Then, by Lemma [2] 
and (I), (vP) ~f — ►* i v P) sucn that Candidate p and Candidate, are in <;' . It can be 
shown, following the reasoning of SectionQ] that eventually: either c and c are released; 
or, some a is released such that for some point p' and synchronizer s, we have s(p') = a 
and either p G dom(s) or c/ G dom(s). In the former case, P makes the corresponding 
reduction, and we are done. In the latter case, the action complementary to a is released 
in the next step; then P makes the corresponding reduction, and we are done. 

On the other hand, if there are no p 1— > c and q 1— > c in ~<f\ then by (1) there must 
be some p and c/, and s and s', such that s(p) = c, s'(c/) = c, and one of the following 
sub-states is in £ : 

{Candidate p , Selects (p), Reject (p), Done s (p), Retry,,} 

and one of the following sub-states is in <; : 

{Candidate,, SelecV(g), Reject(c/), Done s /(c/), Retry,,,} 

So either Candidate^ and Candidate, are in ~cf, or p and q are in sub-states reachable 
from Candidate^ and Candidate,; in either case, we proceed as before. 



